Some prior art systems compile bytecodes of a computer program expressed in the Java programming language into native executable code (i.e. machine instructions) in an ahead of time (AOT) manner. Native code that is compiled ahead of time is typically frozen, which enables it to be shared among multiple users (as illustrated by the sharing of Java Class X in FIG. 1), but it has the drawback that the frozen code cannot be easily updated.
Another technology that is employed by several Java Virtual Machines (JVMs) to allow updates to Java code is dynamic compilation, which is also called Just-in-Time (JIT) compilation. In JIT compilation, Java bytecodes are compiled into native machine code, only on demand as and when needed (instead of compilation ahead-of-time). Specifically, bytecodes are interpreted by a JVM initially, until they are found to be heavily used, at which time they are compiled by the JIT compiler. The compiled code is typically discarded by the prior art systems known to the current inventors, when execution terminates.
To the inventors' knowledge, each instantiation of a Java application of prior art JIT systems runs in one process, and each process has it's own copy of any native machine code which has been compiled on demand, during the course of that VM instance. The above-described VM instances may be implemented by database server processes, such as processes 113 and 117 (FIG. 1). This figure is further described in US Patent Application 2001/0047436 and in U.S. Pat. No. 6,829,761 both by Harlan Sexton et al. and both of which are incorporated by reference herein in its entirety, as background. Sexton describes several different kinds of memories, including a database instance memory 120 which may be used to store read-only data and instructions that are executed by server processes 113 and 117.
See also U.S. Pat. No. 6,854,114 granted to Harlan Sexton et al, which is also incorporated by reference herein in its entirety, as background. In this patent, Sexton describes multiple VM instances accessing the shared state area illustrated at the bottom of FIG. 1. Three clients shown at the top of FIG. 1 have established three sessions through a server. A session is typically, although not necessarily, bounded by the time a single client connects to the server. When a client causes a program in the form of Java code to run within a session, it is termed as a call. A call can be started in different ways, e.g. as follows: (a) a SQL client program runs a Java stored procedure, (b) a trigger runs a Java stored procedure, and (c) a PL/SQL program calls a Java code. Typically, after a client establishes a session, a call begins and the program (which may be some combination of Java, SQL, or PL/SQL code) is run to completion, and then the call ends. Hence, each client performs the following: (a) connects to the database and opens a session, (b) runs the program within the database (and this is referred to as a call), (c) continues to work within the session, performing as many calls as required, and (d) ends the session.
Within a session of the type shown in FIG. 1 and described above, each client has its own Java environment. Oracle Corporation's relational database management system makes it appear to any given client as if a separate, individual JVM was started for that client's individual session. Within each session, Oracle transparently executes a shared JVM that manages the scalability of applications. Every call from a single client is managed within its own session, and a call from each client is handled separately. Oracle's shared JVM maximizes sharing of read-only data between clients while minimizing the per-session incremental footprint for each client. Variables defined as static by a program are local to each client even if the same program is executed by the shared JVM. No client can access the static variables of other clients, because any given session's memory is not accessible to any other session. Because each client runs Java application calls within its own session, the activities of each client are separate from and independent of any other client. The entire state of each Java program is private and exists for the entirety of a session. During a call, a client can store objects in static fields of different classes, which are available in the next session.
Referring to FIG. 1, in session 1, a call that involves services provided by the virtual machine is currently being processed by a system thread using VM instance 1. In session 3, a call that involves services provided by the virtual machine is currently being processed by a system thread using VM instance 3. Both VM instance 1 and VM instance 3 share access to the shared state area, which in the illustrated embodiment includes data for Java class X. In session 2, no call is currently active. To the inventors' knowledge, prior art systems create multiple VM instances within the server and run them in either separate processes, or using system threads, which typically cause a given program that is required by each VM instance to be redundantly and independently compiled by each VM instance, thereby wasting computational power. Moreover, to the inventors' knowledge, such prior art systems also maintain multiple copies of a program's executable code redundantly in memory, one copy maintained by each session independently of any other session, which wastes memory. Although creating and storing multiple copies of a program's compiled native code is simpler, this method does not scale well.